Description

Fixes #3027.

A function call in an insert values list is reported to ParsedPreparedStatement.useFunction only by a listener callback
on the ANTLR4 parse tree (insertParameterFuncExpr). A statement the bundled grammar cannot match is still given a parse
tree, completed by error recovery, which skips the tokens the parser recovered on: a function call among them is never
reported, so useFunction stayed false while a function was present - e.g. INSERT INTO t (v1, v2) VALUES (?, hex(x'AB')), valid ClickHouse the grammar has no hex string literal for. ConnectionImpl#prepareStatement uses that
flag to decide whether an insert can be written with the beta RowBinary writer (which requires a values list of
parameter placeholders only), so with beta.row_binary_for_simple_insert=true such a statement was routed to the writer,
where a literal function-call column cannot be written. Since a recovered tree cannot tell whether a function call is
present, both ANTLR4 backends now assume one for an insert that could not be parsed without errors, so the statement
takes the generic parameter substitution path - as it already did for a function call the grammar matches. The default
JAVACC backend derives function usage from the SQL itself and is not affected.

Changes

• jdbc-v2/.../internal/SqlParserFacade.java: added assumeFunctionInValuesListOfRecoveredParseTree(...), called from
  the existing isHasErrors() branch of ANTLR4Parser#parsePreparedStatement and of the override in
  ANTLR4AndParamsParser (the two entry points that build a ParsedPreparedStatement from an ANTLR4 parse tree). It
  sets useFunction for an insert only - in these backends the flag describes the insert values list.
• CHANGELOG.md: bug-fix entry, including that the assumption applies to any insert parsed with errors.

Test

• BaseSqlParserFacadeTest#testInsertUseFunction (runs for all three parser backends): a @DataProvider pinning
  useFunction for a values list of placeholders only (false), a function call the grammar matches (now(),
  toString(?) - true), and a function call it cannot match (hex(x'AB') in the first value, in the second value, and
  in the second of two value groups - true). Each row also pins whether the statement parses without errors (ANTLR4
  backends), so the rows keep covering the error-recovery branch. 6 rows fail on main for ANTLR4 and
  ANTLR4_PARAMS_PARSER, none with the fix; the JAVACC rows pass before and after.
• BaseSqlParserFacadeTest#testUseFunctionOfUnparseableSelect: contrast case - a SELECT that cannot be parsed keeps
  reporting no function usage in the ANTLR4 backends (skipped for JAVACC, which reports any function use).
• WriterStatementImplTest#testInsertWithUnparseableFunctionNotWrittenWithRowBinary (integration, both ANTLR4
  backends): through prepareStatement with the beta writer enabled, INSERT INTO t (v1, v2) VALUES (?, hex(x'AB')) is
  not a WriterStatementImpl and stores v2 = 'AB'; a values list of placeholders only still is a WriterStatementImpl
  and stores its bound value. Both rows fail on main (routed to the writer).
• mvn -pl jdbc-v2 test: 1322 tests, 0 failures. Focused integration run (WriterStatementImplTest,
  PreparedStatementTest): 77 tests, 0 failures.

Pre-PR validation gate

• Deterministic repro confirmed (parser-level and through prepareStatement)
• Root cause documented above
• Fix targets the root cause, on the live runtime path (prepareStatement → ConnectionImpl routing)
• Tests fail without the fix, pass with it; no existing test changed or weakened
• No existing tests broken
• Convention compliance verified per AGENTS.md / docs/changes_checklist.md (new package-private method with the
  smallest visibility and focused tests; debug-level log on a non-hot error path that logs no SQL values;
  parametrized @DataProvider instead of near-identical methods; no public API or configuration change, so
  docs/features.md needs no update)

Related

Same family as #3019 / #3025: parse-tree-derived fields of a recovered ANTLR4 tree. This PR fixes a different field
(useFunction) with a different consumer (the RowBinary routing decision) and is independent of the PRs for those.